Group Signature Scheme With Improved Efficiency, in Particular in a Join Procedure

ABSTRACT

A method for managing a group signature scheme includes in a setup procedure for group initialization, generating, by a group manager, a group public key. In a join procedure for the group manager to add a new member to the group, the method includes generating by the new member, user information, and providing the generated user information to the group manager, and computing, by the group manager, membership information for the new member based on the user information received by the new member and on the group public key, and providing to the new member the computed membership information. In particular, the membership information is computed, by the group manager, as a function of the inverse of a given hash function of the user information. In a signing procedure for a group member to sign a message on behalf of the group, the method includes: using, by the group member, the membership information and the user information. The method further includes the use of digital certificates, in order for the group member to prove to the group manager the possession of said user information.

TECHNICAL FIELD OF THE INVENTION

The present invention relates in general to electronic signaturetechniques, and in particular to the management of a group signaturescheme having an improved efficiency, specifically in a join procedure.

BACKGROUND ART

The concept of group signature has been introduced in the early 90s forsecure electronic payment applications, and from then onwards it hasbeen widely applied in many other areas where a combination was neededof security (e.g. in terms of avoiding fraudulent behaviors orcollusions of group members) and privacy (e.g. in terms of preservinganonymity of the group members).

As is known, group signatures are a particular sort of digitalsignatures, according to which members which are registered to a groupare allowed to sign on behalf of the group, while preserving theiranonymity. A verifier must be able to ascertain that the signature hasbeen made by a member of the group, but he must not be allowed to tracethe identity of the member. However, under certain circumstances, e.g.under a legal dispute, any group signature must be “openable”, in orderto identify, without ambiguity, the identity of the signer. Moreover,nobody must be accorded the possibility to forge a group signature.

Each group may be managed by a central authority, who is in charge ofregistering new members willing to join the group and of revokingmembership to previous members of the group, and who is able to “open”signatures to prove the real identity of the signer. This centralauthority is generally called group manager (GM), or even group leaderor group center, while the participants of the group are called membersor players. A group is called “dynamic” if members can join the group orbe revoked from the group, or also have some associated parametersmodified, during the group life cycle.

The following is a list of algorithms and procedures that any groupsignature scheme should provide:

-   -   SETUP: a procedure for the initialization of the group, and in        particular for the definition of group parameters, and of group        manager public and private keys;    -   JOIN: an interactive procedure between the group manager and a        user willing to participate in the group, according to which the        user identity is registered and, depending on the        implementation, a secret or aggregation key, a certificate, or a        membership information is provided to the user;    -   SIGN: an algorithm for the computation of a group signature of a        message by a group member, as a function of his/hers personal        data;    -   VERIFY: an algorithm which can be executed by any user (acting        as a verifier) to prove that a group signature originated from a        registered group member;    -   OPEN: an algorithm for the identification of the signer identity        by the group manager, given a signed message, a valid group        signature and group public data (and secret data known, ideally,        only to the group manager); and    -   REVOKE: a procedure for the group manager to remove a member        from the group, revoking his/her possibility to sign on behalf        of the group.

Moreover, the following is a list of properties which a group signaturescheme should meet:

-   -   CORRECTNESS: a signature correctly generated by a group member        must be recognized as valid by the VERIFY algorithm;    -   UNFORGEABILITY: only the group members must be able to sign        messages on behalf of the group;    -   ANONIMITY (or UNTRACEABILITY): it must be computationally        unfeasible (to everybody except the group manager) to trace the        real identity of a signer from a valid group signature;    -   UNLINKABILITY: determining whether two group signatures stem        from a same group member must be computationally unfeasible;    -   EXCULPABILITY (or NO-FRAMING): neither a coalition of group        members, nor the group manager must be allowed to sign on behalf        of another group member;    -   TRACEABILITY: the group manager must always be able to open a        valid group signature and to determine the real identity of the        signer; and    -   COALITION-RESISTANCE: any given subset of group members, sharing        their respective secrets, must not be allowed to compute a valid        group signature which is not openable by the group manager.

Many group signature schemes have been proposed in the past, but so farnone has proved to be completely satisfactory in terms of implementedprocedures and properties.

In particular, D. Chaum and E. Van Heyst were among the first tointroduce the concept of group signature in 1991 in their paper GroupSignatures, In D. W. Davies, editor, Eurocrypt '91, volume 547 of LNCS,pages 257-265, Springer-Verlag, 1992. In their paper, Chaum and VanHeyst introduced the notion of group signature allowing the members of agroup to sign data on behalf of the group, in such a manner that: onlygroup members can sign messages; anyone is able to verify the validityof a group signature, but he/she is not allowed to know the identity ofthe signer; in case of a dispute, it is possible to open the signature(with or without the cooperation of the group members) to reveal theidentity of the person that signed on behalf of the group. Inparticular, four different group signature schemes are proposed, whichare not all based on the same cryptographic assumptions: the first oneprovides unconditional anonymity, while, according to the others,anonymity is protected computationally; moreover, in some schemes acentralized entity is required during the setup only, while in otherschemes every member may create autonomously his group.

J, Benaloh, M. de Mare, One-Way Accumulators: A DecentralizedAlternative to Digital Signatures, In: Advances inCryptography—Eurocrypt '93, LNCS 765, pages 274-285, Springer-Verlag,Berlin, 1994, discloses the use of a one-way accumulator incryptographic protocols, e.g. for membership testing. In particular, afunction h(x, y) that is a. one-way accumulator produces, given astarting value x₀εX and a set of values y₁, Y₂, . . . Y_(m)εY, aresulting value z, computed by the application of h, which isindependent from the order of the y_(i) values:

z=h(h(h( . . . h(h(h(x,y ₁),y ₂),y ₃), . . . y _(m−2)),y _(m−1)),y _(m))

In addition, the fact that h is a one-way accumulator means that givenxεX and yεY it is computationally unfeasible to find, for a given y′εY,an x′εX such that h(x, y)=h(x′; y′). If the values y₁, y₂, . . . y_(m)are associated to the users of a cryptosystem, the accumulated value zof all the y_(i) can be computed, and a user holding a particular y_(j)can compute a partial accumulated z_(j) of all y_(i) with i≠j. Theholder of y_(j) can then demonstrate that y_(j) was a part of theoriginal accumulated value z, by presenting z_(j) and y_(j) and provingthat z=h(z_(j); y_(j)). A person who wishes to forge a particular y′would be faced with the problem of constructing an x′ with the propertythat z=h(x′; y′), i.e. a computationally unfeasible computation. Asfunction h, the authors suggest the use of a modular exponentialfunction:

h(x,y)=xy mod n

where n is a large rigid integer (i.e. n=(2p′+1)(2q′+1), with 2p′+1 and2q′+1 safe primes, p′ and q′ odd primes, and |2p′+1|=|2q′+1|).

J. Camenisch and A. Lysyanskaya, Dynamic accumulators and application toefficient revocation of anonymous credentials, In: Crypto 2002, LNCS2442, pages 61-76, Springer-Verlag, 2002, discloses another scheme basedon the use of accumulators. In particular, this scheme uses a dynamicaccumulator, i.e. an accumulator that allows to dynamically add anddelete inputs, such that the cost of an add or delete is independent ofthe number of accumulated values. The scheme allows a group member toproduce a simplified and efficient authorization proof, that is, havingthe property that the complexity of the signature verification and groupmembership verification are independent from the number of currentlyrevoked group members or total group members. According to an aspect ofthis scheme, in a setup procedure, the group manager chooses a number ofprecomputed values e_(i) and accumulates them in order to compute agroup public key u, as:

u=f _(n)(u,Πe _(i))

wherein f_(n) is a dynamic accumulator function; in particular, thenumber of precomputed values e_(i) is equal to a maximum number of usersthat can join the group. In a join procedure, the group manager assignsto the new member a respective one of the precomputed values e_(i) (inparticular, a value that was not yet associated to existing members),and computes a membership value c_(i) for the new member, as:

$c_{i} = u^{\frac{1}{e_{i}}}$

i.e. as a function of the group public key u, and the inverse l/e_(i) ofthe associated precomputed value. Accordingly, updates by the groupmanager and/or by the group members are required only in case ofdeletion of members, or in the event that the group manager runs out ofprecomputed values e_(i).

OBJECT AND SUMMARY OF THE INVENTION

The Applicant has observed that a common problem affecting some of theknown schemes is that the length of the signature and/or a group publickey size (i.e. the number of bits of the signature and/or group publickey) vary with the group size, in particular increase linearly with thenumber of group members, making this group signature method unsuitablefor large groups. The Applicant has also observed that it is not alwayspossible to add new members to an existing group, and, even when it ispossible, adding new members requires a modification in the group publickey, and accordingly the necessity for the group manager to communicatethe new public key to all the existing members. In some schemes thegroup manager needs to contact the group members to open a signature.

Other schemes having fixed signature size and fixed group size have beenproposed, which allows for joining of new members without modificationof a group public key. However, a strong limitation of these schemes isthe necessity to define in a setup procedure a maximum number of groupmembers, and the necessity to modify the group public key, andaccordingly the membership values associated to all group members, inthe event that the number of members exceeds this maximum number.

Furthermore, most of the known schemes reveal not provably secure (ornot secure at all) or extremely inefficient, in particular in terms ofmember revocation procedures. In particular, as far as revocation ofgroup members is concerned, identity revocation is a critical problem,and what is required to a group signature scheme is the possibility toimmediately revoke group members. This means that revoked members mustnot be allowed to sign on behalf of the group since the very moment inwhich they have been removed from the group. Known solutions, also inthis respect, have proved not to be completely satisfactory.

Therefore, a need is surely felt for a group signature scheme having animproved efficiency, in particular of a join procedure, allowing thejoin of an unlimited number of members without the necessity to modify agroup public key; advantageously, the group signature scheme should alsoprovide an improved security from attacks of various nature, anefficient revoke procedure, and the possibility for a group manager andfor a third party to identify without ambiguity the identity of asigner.

The aim of the present invention is therefore to satisfy the above need,and in particular to implement a group signature scheme providing someor all of the following properties:

-   -   the group public key size does not increase when new group        members are added;    -   the group public key does not change when new group members are        added to the group, or new keys are assigned to existing group        members;    -   the group member private/public keys used for group signatures        do not change when new members are added;    -   an unlimited number of members can join the group after the        group has been set up, while keeping the group public key        constant (assuming no revocations);    -   standard signatures and well known cryptographic functions are        used to produce the group signatures, and thus the verification        of a signature may use well known algorithms, allowing        performance and security properties similar to those observed        for standard signatures (both in signing and in verification);    -   the opening (i.e., determining the identity of the signer) of a        group signature does not require any cooperation from group        members, and may be carried out by the group manager alone; when        opening a signature, the group manager is able to prove to a        third party that the signer, and no one else, made that        particular group signature (so called “Unforgeability of        traceability”, as described in detail later on);    -   an improved resistance is achieved to attacks of various nature,        such as to collusions between members.

This aim is achieved by the present invention in that it relates to amethod for managing a group signature scheme, as defined in claim 1, toa processing system as claimed in claim 31, and to a computer programproduct as defined in claim 33.

Specifically, according to an aspect of the proposed signature scheme,which makes use of one-way accumulator techniques, a group manager setsa group public key value, and a user who wants to join the groupgenerates, and sends, encrypted and signed, to the group manager, a setof keys which are the public parts of a set of cryptographic asymmetrickey pairs. The group manager then computes an initial accumulation valuefor a one-way accumulator as a function of the group public key (i.e.the final value of the accumulator) and the user public keys, and sendsthis initial accumulation value to the user, who will then use it, alongwith his cryptographic keys, to sign messages on behalf of the group. Inparticular, the initial accumulation value is computed as a function ofthe inverse of a given function (advantageously a hash function) of theuser public keys. The group public key remains fixed in size and doesnot change when new members are added, since, according to the proposedscheme, it is a value set by the group manager in the set-up of thegroup, independently of the sensitive information of the various groupmembers. Furthermore, according to other aspects of the invention, aparticular function is proposed for the one-way accumulator, whichallows avoiding possible attacks and achieving greater overall systemsecurity. Also, the proposed group signature scheme envisages the use ofdigital certificates, one for each member of the group, by means ofwhich the group members are able to provide to the group manager a proofof possession of the respective cryptographic keys, which can be used bythe group manager to identify the signer of a message; in particular,this allows achieving an “Unforgeability of traceability” property,which is described in what follows. Moreover, the proposed solutionallows easy and efficient revocation procedures, which can be performedissuing to the group members a single small piece of data and exploitingsome mathematical properties of the one-way accumulator function; inparticular, the revocation is not based on CRLs (Certificate RevocationLists).

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention, preferredembodiments, which are intended purely by way of example and are not tobe construed as limiting, will now be described with reference to theattached drawings, wherein:

FIG. 1 shows schematically a processing system where the group signaturescheme according to an aspect of the present invention may beimplemented;

FIG. 2 shows a schematic diagram illustrating procedures implemented bythe group signature scheme according to the invention;

FIG. 3 shows a flow chart illustrating operations carried out to performa join procedure in the group signature scheme of FIG. 2;

FIG. 4 shows a flow chart illustrating operations carried out to performa sign procedure in the group signature scheme of FIG. 2; and

FIG. 5 shows a flow chart illustrating operations carried out to performa revoke procedure in the group signature scheme of FIG. 2.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

The following discussion is presented to enable a person skilled in theart to realize and use the invention. Various modifications to theembodiments will be readily apparent to those skilled in the art, andthe general principles herein may be applied to other embodiments andapplications without departing from the spirit and scope of the presentinvention. Thus, the present invention is not intended to be limited tothe embodiments shown, but is to be accorded the widest scope consistentwith the principles and features disclosed herein and defined in theattached claims.

FIG. 1 shows a computer system 1 in which the group signature schemeaccording to the present invention may be implemented, and including aplurality of member processing devices 2 a (e.g. personal computers),each of them belonging to a group member A_(i), and a central processingdevice 2 b (e.g. a personal computer) belonging to a central authority(in the following “group manager”) of the group. Each processing devicecomprises a central processing unit (CPU), a video monitor 3, a keyboard4, a mouse 5, storage devices 6 including hard disk drives and othertypes of permanent and removable storage media, such as RAM or ROMmemories. A communication link 8 (e.g. through a wireless network) isprovided between the central processing device 2 b and the memberprocessing devices 2 a, in order to allow an exchange of informationtherebetween. As it will be discussed in detail later on, each groupmember A_(i) is able to sign a message on behalf of the group by meansof the respective member processing device 2 a, while the group manageris able to control the group signature scheme by means of the centralprocessing device 2 b, and in particular to verify the validity of asignature performed by a group member, to add/revoke a member to/fromthe group, to open a signature, etc.

FIG. 2 shows a schematic diagram illustrating the procedures that areexecuted within the group signature scheme according to an aspect of thepresent invention. In particular, in a system bootstrap and groupcreation procedure (so called SETUP procedure), block 10, the groupmanager generates a symmetric encryption key GMK (Group Manager Key),and publishes a signed cryptographic hash of the symmetric encryptionkey GMK, e.g. the result of the application-of a hash function to thesymmetric encryption key GMK, signed with a group manager private keyK^(S) _(GM). The hash function can be, for example, the one known asSHA-1 (Secure Hash Algorithm, Revision 1) and described in NationalInstitute of Standards and Technology, NIST FIPS PUB 180-2, Secure HashStandard. August 2002. Moreover, the group manager generates a largerigid integer n and assigns a value to a group public key GK (modulo n)as GK=f_(n)(X,y), with X, y integer random numbers within the range [2,n−1] and f_(n) being an accumulator function, which will be discussed indetail later on; the group manager then publishes the large rigidinteger n and the group public key GK with a signature. As previouslydiscussed, the large rigid integer n is such that n=(2p′+1) (2q′+1),with 2p′+1 and 2q′+1 safe primes, p′ and q′ odd primes, and|2p′+1|=|2q′+1|). As it will be clear in the following, the values ofthe safe primes 2p′+1 and 2q′+1 must be kept secret by the groupmanager, to maintain the security of the group signature scheme.Moreover, during the SETUP procedure, each user willing to join thegroup also receives a Digital Certificate (e.g. the one known as X.509)from a recognized Certification Authority.

After the SETUP procedure, the following procedures may be executed:

-   -   JOIN (block 11): for a new member to join the group;    -   SIGN (block 12): for a group member to sign a message on behalf        of the group;    -   VERIFY (block 13): for a verifier (a group member, the group        manager, or a given third party) to verify a signature produced        by a group member;    -   OPEN (block 14): for the group manager to ascertain the identity        of a signer, given a valid group signature; and    -   REVOKE (block 15): for the group manager to revoke to one or        more group members the possibility to sign on behalf of the        group.

The above procedures will now be described in detail.

Join Procedure

With reference to FIG. 3, when a user wants to join the group, to becomea group member A_(i) (in the following the user is therefore referred toas group member), he/she first generates a set of N asymmetric key pairs<K^(S) _(i,j), K_(i,j)>, block 20, where K^(S) _(i,j) denotes theprivate key and K_(i,j) the public key of the pair (1≦j≦N). For example,the asymmetric key pairs can be generated with the RSA algorithm asdescribed in R. Rivest, A. Shamir, and L. Adleman, A Method forObtaining Digital Signatures and Public-Key Cryptosystems,Communications of the ACM, 21 (1978), pp. 120-126; or with the DSAalgorithm, as described in National Institute of Standards andTechnologies, NIST FIPS PULB 186-2, Digital Signature Standard, January2000. These keys will be used by the group member A_(i) to sign messageson behalf of the group. It should be noted that although N (i.e. thenumber of asymmetric key pairs) can be different for each-group member,in the following detailed description it is assumed that each membergenerates the same number N of asymmetric key pairs.

Then, block 22, the group member A_(i) makes a so-called “proof ofpossession” of each generated private key K^(S) _(i,j), securely bindingthe assertion of possession to his/her identity as claimed in therespective Digital Certificate that was previously issued to him/her bythe recognized Certification Authority. In detail, according to anembodiment of the present invention, the group member A_(i) computes thefollowing proof of possession AE_(i,j):

AE _(i,j) =Sig1(S _(i) ,K _(i,j)),Sig2(K ^(S) _(i,j) ,Sig1(S _(i) ,K_(i,j)))

where l≦j≦N; Sig1(x, y) and Sig2(x, y) are the signature of y usingprivate key x and include a signed text and a Digital Certificate (or anunambiguous reference to it) issued by the recognized CertificationAuthority; and S_(i) is a private key associated to a certified publickey P_(i) included in the member Digital Certificate. In particular, aswill be described later, the above proof of possession AE_(i,j) allowsthe group manager to prove to a third party that a particular signermade a group signature (the so called “Traceability” property), and alsoto prove unambiguously that the signer and no one else could make thatparticular group signature (the so called “Unforgeability oftraceability” property). In particular the “Unforgeability oftraceability” property can be defined as follows: during an OPENprocedure, the secrets determined by the group manager and thesignatures must unambiguously demonstrate, even to third parties, whichmember, between two or more claiming to have executed a signature, isthe real signer; this property must still be satisfied, if the membersprivate keys are not available, or in case of collusion with the groupmanager.

According to a different embodiment of the present invention, the groupmember A_(i) computes the following alternative expression for the proofof possession AE_(i,j):

AE _(i,j) =Sig1(S _(i) ,M _(i)),Sig2(K _(i,j) ,M _(i))

where M_(i)=ID_(i), K_(i,j), and ID_(i) is an identifier of the groupmember A_(i) (e.g. the subject included in the member DigitalCertificate).

Afterwards, the group member A_(i) sends to the group manager through anencrypted channel, block 24, the complete set of the proofs ofpossession AE_(i,j), each of them incorporating a respective public keyK_(i,j). All the data are sent in an encoded format to make it easierfor the group manager to associate each public key K_(i,j) to thecorresponding proof of possession AE_(i,j). The group manager extractsthe data and verifies the signatures against the proper public keys; inparticular the group manager collects all the public keys K_(i,j)(1≦j≦N) of the group member A_(i). It should be noted that the set ofcertified public keys P_(i), and the set of group member public keysK_(i,j) are not required to be handled or be compatible with a samecryptosystem.

The group manager then computes, block 26, an initial accumulation valueC_(i) (computed mod n) for the group member A_(i), such that a one-wayaccumulator function f_(n)(x, y) of the public keys K_(i,j) of the groupmember, using the initial accumulation value C_(i) as initial secretproduces, as overall value, the group public key GK, i.e.:

GK=f _(n)(C _(i) ,K _(i,1) ,K _(i,2) , . . . , K _(i,N))

As will be discussed in detail, the initial accumulation value C_(i)represents a membership information for the new member.

As is known, the meaning of the one-way accumulator function f_(n)(x, y)is:

f _(n)(x,y ₁ ,y ₂ , . . . y _(N))=f _(n)(f _(n)(f _(n)( . . . (f _(n)(f_(n)(x,y ₁),y ₂) . . . y _(N−2)),y _(N−1)),y _(N))

According to a particular aspect of the present invention, the followingone-way accumulator function f_(n)(x, y) is used, in order to avoidpossible attacks, such as collusions between group members, and to makethe security of the group signature scheme independent of the memberpublic keys representation:

f _(n)(x,y)=x ^(b(y))mod n

where the exponent function b(y) is given by:

${b(y)} = \left\{ \begin{matrix}{h(y)} & {{if}\mspace{14mu} {h(y)}\mspace{14mu} {is}\mspace{14mu} {an}\mspace{14mu} {odd}\mspace{14mu} {integer}} \\{{h(y)} + 1} & {{if}\mspace{14mu} {h(y)}\mspace{14mu} {is}\mspace{14mu} {an}\mspace{14mu} {even}\mspace{14mu} {integer}}\end{matrix} \right.$

h(y) being an appropriately chosen hash function (e.g. the standardSHA-1 function), and φ(n) being the known Euler phi-function, whichoutputs, for a given n>1 the number of positive integers <n which arerelatively prime to n. As it will be detailed later, the output of theexponent function b(y) should be an odd number, and this is the reasonfor which b(y) should be equal to h(y)+1 just when the value of the hashfunction h(y) is an even integer.

According to an aspect of the invention, the group manager computes theinitial accumulation value C_(i) for the group member A_(i) as follows:

Y′=rad(b(K _(i,1)),GK)mod n

Y″=rad(b(K _(i,2)),Y′)mod n

Y′″=rad(b(K _(i,3)),Y″)mod n

. . .

C _(i) =Y ^((N))=rad(b(K _(i,N)),Y ^((N−1)))mod n

C _(i)=rad(b(K _(i,N)) . . . rad(b(K _(i,2)),rad(b(K _(i,1)),GK)modn)mod n) . . . )mod n

or

C_(i)=GK^([b(K) ^(i,1) ^()]) ⁻¹ ^(. . . [b(K) ^(1,N) ^()]) ⁻¹^(mod φ(n))mod n

the meaning of the function rad(s, t) being the following:

u=rad(s,t)mod n→t≡u ^(s)(mod n)

As shown, the computation of the initial accumulation value C_(i)requires inverting the one-way accumulator exponential function f_(n),i.e. computing the root modulo n of the group public key GK computedusing all the (hashed) group member public keys K_(i,j). As is known,computing the function rad modulo n is feasible only having theknowledge of the factorization of n. This is known as the RSA problem(see, for example A. J. Menezes, P. C. van Oorschot, S. A. Vanstone,Handbook of applied cryptography, CRC Press, 1996, pages 98-99), i.e.given a positive integer n, product of two distinct odd primes p and q,an integer c, and a positive integer e such that gcd(e, φ(n))=1 (gcdbeing the greatest common denominator), find an integer m such thatm^(e)≡c (mod n); this problem can be solved only if the factoring of nis known. In the present case, the group manager (and no one else, hencethe security of the group signature scheme) knows the factoring of n,since n is the product of the two large rigid integer (2p′+1) and(2q′+1). Also, gcd(b(y), φ(n))=gcd(b(y), 4p′q′) must be equal to 1. Toreduce the probability of having a gcd different from 1, then the resultof the hash function h(y) is added by 1 if and only if it is even,giving, as a result, an odd number. If the gcd is different from 1 (andequal to p′ or q′, or p′q′), then the key used to compute the hashshould be discarded. This event should be very improbable, if p′ and q′are large primes.

According to a different aspect of the present invention (which is moreefficient especially when each joining member has several public keysK_(i,j)), the initial accumulation value C_(i) is calculated accordingto the following expression:

C_(i)=X^(b(y)[b(K) ^(i,1) ^()b(K) ^(i,2) ^() . . . ·b(K) ^(i,N) ^()]) ⁻¹^(mod φ(n))mod n

i.e.

C_(i)=GK^([b(K) ^(i,1) ^()b(K) ^(i,2) ^()· . . . ·b(K) ^(i,N) ^()]) ⁻¹^(mod φ(n))mod n

It should be noted that according to both described expressions, theinitial accumulation value C_(i) is computed as a function of the groupmember public keys K_(i,j), in particular as a function of the inverseof a given function of the group member public keys K_(i,j).Advantageously, the given function is the hash function h(y), and thefunction which is applied to the inverse of such given function is anaccumulator function.

Next, block 28, the group manager sends (encrypted and authenticated) tothe group member A_(i) the previously computed initial accumulationvalue C_(i). As it will be detailed later, the group member will thenuse this initial accumulation value C_(i) and one of his/hers asymmetrickey pairs <K^(S) _(i,j), K_(i,j) to sign a message on behalf of thegroup.

Furthermore, block 30, in order to be able to open signatures performedby the group member (in a manner that will be described in detail), thegroup manager sends (encrypted and authenticated) to the group memberA_(i) the following expression, i.e. the encrypted and signed proof ofpossession AE_(i,j) for each public key K_(i,j):

Enc(GMK,AE_(i,j)),Sig(K^(S) _(GM),K_(i,j)∥Enc(GMK,AE_(i,j)))

where l≦j≦N, and Enc(y, x) is the symmetric encryption of x using theencryption key y, and x₁∥x₂ denotes the concatenation of x₁ with x₂.Also, the group manager adds to the signature of the proof of possessionAE_(i,j) the respective public key K_(i,j), in order to prove to thegroup member A_(i) that the expression AE_(i,j) has been validly boundedto his/hers public key K_(i,j) (note that the group member A_(i) doesnot know the symmetric encryption key GMK of the group manager). Thismode of operation is advantageous in that it implies that the groupmanager does not need to store all the public keys K_(i,j) of the groupmembers, in order to subsequently be able to verify and open the groupmember signatures. In fact, as will be detailed later, the group managerwill make use for that purpose of the encrypted and signed proofs ofpossession. Anyway, as will be clear from the following description, inorder to be able to revoke the group member A_(i), it is more efficientfor the group manager, at the JOIN time, to compute and store just arevocation value V_(i) for the group member A_(i), as:

V _(i) =[b(K _(i,1))·b(K _(i,2))· . . . ·b(K _(i,N))]⁻¹ mod φ(n)

According to an alternative embodiment of the present invention, whichis advantageous in case computation effort and communication bandwidthbetween the group members and the group manager have to be reduced, thegroup manager guarantees for the availability of the proofs ofpossession AE_(i,j) for the group member A_(i). The generation of asymmetric encryption key GMK in the SETUP procedure can thus be avoidedby the group manager, and the communication to the group member of thesigned and encrypted proofs of possession (block 30) can be replacedwith a procedure where secrecy and integrity of the proofs of possessionAE_(i,j) are just preserved by the group manager, e.g. by storing theproofs of possession AE_(i,j), block 32, in an encrypted database whosedecryption key is hold by the group manager (for example stored in thegroup manager storage device 6), so that they can be accessed on thebasis of the public keys K_(i,j) and used whenever a signature has to beopened. The “Unforgeability of traceability” feature is obtainedpreferring as proof of possession the first embodiment mentioned in theJOIN PROCEDURE.

Having described the JOIN procedure implemented in the group signaturescheme according to the present invention, it should be noted that thevalue of the group public key GK, which is, among other things,necessary to verify group membership, is invariant with respect to thejoining of a new member; also, the initial accumulation valuespreviously computed by the group manager for other group members havenot changed their values.

Sign Procedure

With reference to FIG. 4, when a group member A_(i) wants to sign amessage M on behalf of the group, he/she uses one of his/hers privatekeys K^(s) _(i,j), to produce a signature Sig(M) of the message M, block40. In particular, in order to achieve unlinkability between twosignatures made by a same group member, the group member A_(i) uses aprivate key that was never used before, i.e. any private key is usedonly once in a SIGN procedure by each group member. The group memberA_(i) then computes, block 42, the one-way accumulator of the respectiveinitial accumulation value C_(i) along with all its public keys, exceptfor the public key K_(i,j) associated with the private key K^(s) _(i,j)used for signing, obtaining a partial accumulation value PGK_(i,j):

PGK _(i,j) =f _(n)(C _(i) ,K _(i,1) , . . . K _(i,j−1) ,K _(i,j+1) , . .. K _(i,N))

Then, the group member publishes (without any contact with the groupmanager) the following set of data, block 44:

1. M, Sig(K^(s) _(i,j), M);

2. K_(i,j), PGK_(i,j); and

3. Enc(GMK, AE_(i,j)), Sig(K^(s) _(GM), K_(i,j)∥Enc(GMK, AE_(i,j))) i.e.the encrypted and signed proof of possession of the private key used forsigning.

According to the previously described alternative embodiment of thepresent invention, according to which the group manager GM guaranteesfor the availability of the proof of possession AE_(i,j) whenever asignature has to be opened, the third piece of information of the aboveset of data is not going to be published as it was not received from thegroup manager by the group member. This is advantageous since it reducesthe amount of data that is sent for each signature through thecommunication link 8.

It should be noted that, since any private key should be used only onceby any group member, it is possible for a group member to run out ofprivate keys. In this situation, more private keys can be generated bythe group member, and his/hers parameters (in particular the initialaccumulation value) will be updated in a manner which is altogethersimilar (and accordingly it will not be described again) to what hasbeen described for the joining of a new member. Clearly, the assignmentof new keys to a member does not imply any modification to the value ofthe group public key GK, nor to the initial accumulation values assignedto the other group members.

Verify

According to the proposed signature scheme, anyone may verify thesignature produced by a group member A_(i) by checking that:

1. Sig(K^(s) _(i,j), M) is the signature of the message M using theprivate key K^(s) _(i,j);

2. GK=f_(n)(PGK_(i,j), K_(i,j)) i.e. the one-way accumulator function ofthe public key K_(i,j), associated to the private key K^(s) _(i,j) usedfor signing, and of the partial accumulation value PGK_(i,j) gives thegroup public key GK;

3. Sig(K^(s) _(GM), K_(i,j)∥Enc(GMK, AE_(i,j))) is valid.

Again, according to the previously discussed alternative embodiment ofthe present invention, if computation effort and communication bandwidthbetween the group members and the group manager must be reduced, thenthe third condition is not going to be verified as it was not receivedfrom the signing group member. This will also reduce the amount ofcomputation required for the VERIFY procedure to be completed.

OPEN

In order to identify the author of a certain group signature, the groupmanager first verifies the signature (as would have done anyone, seeVERIFY procedure), then decrypts the encrypted proof of possessionEnc(GMK, AE_(i,j)) by means of his/hers symmetric encryption key GMK,and finally identifies the signer, examining the identifier field of theproof of possession AE_(i,j). Also, using the proof of possessionAE_(i,j), the group manager is able to unambiguously prove to a thirdparty that AE_(i,j) contains the signature of K_(i,j) made by the groupmember A_(i), and that A_(i) possesses the private key K^(s) _(i,j)associated with K_(i,j), therefore achieving the required“Unforgeability of traceability” property.

In the alternative embodiment, the group manager first retrieves theproof of possession AE_(i,j), associated to the signature that must beopened, from the encrypted database and then decrypts it as previouslydiscussed.

Revoke

With reference to FIG. 5, anytime it is possible for the group managerto revoke one or more group members from the group, so that the revokedmembers will no more be able to sign on behalf of the group.

In order to do so, the group manager computes a new group public key GK(block 50), as described in the SETUP procedure, and a new initialaccumulation value C_(i) for each not-revoked group member (block 52),as:

C_(i)=GK^(v) ^(i) mod n

where V_(i) is the revocation value which has been defined in the JOINprocedure, and GK is the new value of the group public key.

The value of the new group public key GK has to be delivered or madeavailable to group members and signature verifiers (block 54). Eachcomputed initial accumulation value C_(i) has to be delivered to thecorresponding not-revoked member A_(i) (block 56), to be used in theSIGN procedure from now on. Each not-revoked member A_(i) also has tocompute the related partial accumulation values PGK_(i,j) as describedin the JOIN procedure, in order to make a valid signature. Verifierswill be requested to use the new value for the group public key GKagainst the signature issued by a not-revoked member.

In this manner, the revoked member(s) will no longer be able to signmessages on behalf of the group for the very moment of the updating,while the remaining group members will still be able to producesignatures, that will be successfully verified.

It should be noted that it is necessary for the group manager to modifythe value of the group public key GK, in order to effectively revoke themember(s) from the group, since no CRLs (Certificate Revocation Lists)are provided by the proposed signature scheme. Again, it is underlinedthat this is the only situation in which the group public key must bemodified by the group manager, since the JOIN procedure does not requireany modification thereof.

Finally, various modifications to the embodiments will be readilyapparent to those skilled in the art, and the generic principles hereinmay be applied to other embodiments and applications without departingfrom the spirit and scope of the present invention, as defined by theappended claims.

In particular, the one-way accumulator function f_(n)(x, y) could have adifferent expression, for example be defined as:

f _(n)(x,y)=x ^(y) mod n

It can be shown that the above expression is more vulnerable to attacks,but it has the advantage to require easier computations. In this case,the initial accumulation value C_(i) is a function of the inverse of thegroup member public keys K_(i,j), i.e. the above introduced givenfunction is the identity function (f(x)=x).

Also, ideally, each member could in any given moment be provided with asingle public/private key pair. Also, other known algorithms could beused for the described signing and encryption operations within theproposed group signature scheme.

1-33. (canceled)
 34. A group signature scheme management method,comprising: generating, by a group manager, group information, and,during a join procedure for a user to join a group: generating, by saiduser, user information; providing said user information to said groupmanager; computing, by said group manager, membership information forsaid user based on said group information and on said user information;and providing said user membership information to said user; saidcomputing, by the group manager of said user membership informationcomprising: computing said user membership information as a function ofthe inverse of a given function of said user information.
 35. The methodaccording to claim 34, wherein said given function is a given hashfunction.
 36. The method according to claim 35, wherein output of saidgiven hash function is an odd number, and said given hash function is:${b(y)} = \begin{Bmatrix}{h(y)} & {{if}\mspace{14mu} {h(y)}\mspace{14mu} {is}\mspace{14mu} {an}\mspace{14mu} {odd}\mspace{14mu} {integer}} \\{{h(y)} + 1} & {{if}\mspace{14mu} {h(y)}\mspace{14mu} {is}\mspace{14mu} {an}\mspace{14mu} {even}\mspace{14mu} {integer}}\end{Bmatrix}$ where h (y) is a standard hash function or a secure hashalgorithm, revision 1, hash function.
 37. The method according to claim34, wherein said given function is an identity function.
 38. The methodaccording to claim 34, wherein generating, by the user, said userinformation comprises: generating a plurality of user public/privatecryptographic key pairs, and wherein providing said user information tosaid group manager comprises: providing to said group manager, userpublic cryptographic keys of said plurality of user public/privatecryptographic key pairs.
 39. The method according to claim 38, whereinsaid group has a plurality of group members, each one of said groupmembers having a respective number of user public/private cryptographickey pairs.
 40. The method according to claim 38, wherein computing saiduser membership information comprises computing an initial accumulationvalue for an accumulator function, such that a final accumulation valuegiven by said accumulator function computed on said user publiccryptographic keys starting from said initial accumulation value, equalsa value associated with said group information, a function of theinverse of said given function comprising said accumulator function. 41.The method according to claim 40, wherein said accumulator function is aone-way accumulator.
 42. The method according to claim 40, whereingenerating said group information comprises generating a large rigidinteger and said accumulator function is a one-way accumulator of thetype:f _(n)(x,y)=x ^(b(y))mod n where b (y) is said given function.
 43. Themethod according to claim 34, wherein said group has a plurality ofgroup members, each one of the group members generating respective userinformation, and wherein generating, by the group manager, said groupinformation comprises assigning a value to said group informationindependently of said user information provided by said user, and ofsaid respective user information of said group members.
 44. The methodaccording to claim 43, wherein generating, by the user, said userinformation, comprises: generating a plurality of user public privatecryptographic key pairs, and wherein signing comprises: producing asignature based on a given user private cryptographic key of saidplurality of user public/private cryptographic key pairs; producing amembership assertion based on said user membership information; andassociating said membership assertion with said signature.
 45. Themethod according to claim 44, wherein computing said user membershipinformation comprises computing an initial accumulation value for anaccumulator function such that the final accumulation value given bysaid accumulator function computed on said user public cryptographickeys starting from said initial accumulation value, equals a valueassociated with said group information; and wherein producing amembership assertion comprises computing, starting from said initialaccumulation value, a partial accumulation value of said accumulatorfunction computed on all the user public cryptographic keys of saidplurality of user public/private cryptographic key pairs, except for theuser public cryptographic key associated in pairs with said given userprivate cryptographic key used for producing said signature.
 46. Themethod according to claim 34, further comprising: generating, by saiduser, a proof of possession of said user information thereby providing asecure association between said user information and an identity of saiduser; and providing said proof of possession to said group manager. 47.The method according to claim 46, further comprising: encrypting, bysaid group manager, said proof of possession with a personal symmetricencryption key; and providing to said user the encrypted proof ofpossession.
 48. The method according to claim 46, further comprising:signing, by the user, on behalf of the group, by using said userinformation and said user membership information signing, comprisingproducing a signature; and verifying, by a verifier, said signature, byproving a validity of said proof of possession associated with said userinformation.
 49. The method according to claim 46, further comprising:signing, by the user, on behalf of the group, by using said userinformation and said user membership information signing, comprisingproducing a signature; and opening, by the group manager, saidsignature, by extracting from said proof of possession associated withsaid user information an identity information associated with theidentity of said user.
 50. The method according to claim 34, whereinsaid group has a plurality of group members, further comprising, in arevoke procedure for revoking one or more members from the group:generating, by said group manager, a new value for said groupinformation and for the user membership information of the group membersthat are not to be revoked from the group; and providing said new valueto the group members that are not to be revoked from the group.
 51. Themethod according to claim 50, wherein generating said group informationcomprises generating a large rigid integer and said group has aplurality of group members, each one of the group members generating arespective number of user public/private cryptographic key pairs; andwherein generating said new value for the user membership information ofthe group members that are not to be revoked from the group comprises:computing, for each group member, a respective first value with thefollowing expression:V _(i) =[b(K _(i,1))·b(K _(i,2))· . . . ·b(K _(i,N))]⁻¹ mod φ(n) whereφ(n) is the Euler phi-function; and computing said new value for saiduser membership information as:C_(i)=GK^(Vi) mod n where GK is said new value for said groupinformation.
 52. A processing system, capable of being programmed toimplement the method as claimed in claim 34, wherein said groupsignature scheme comprises a plurality of members; and said processingsystem comprises a plurality of electronic signature devices, eachsignature device belonging to a respective member of said members; anelectronic managing device belonging to said group manager; and acommunication link capable of being configured to provide datacommunication between said electronic signature devices and saidelectronic managing device.
 53. A computer program product, comprising acomputer program code capable of being configured to implement, whenloaded in a processing system, the method according to claim 34.